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5 Title: 

AN ARRANGEMENT, A NODE AND A METHOD RELATING TO HANDLING OF 
LOST/DISCARDED DATA- PACKETS 

FIELD OF THE INVENTION 

10 The present Invention relates to an arrangement for allowing 
compensation or correction in relation to lost or unsent data 
packets., on the downlink in a communications system supporting 
communication of packet data and classification of mobile data 
packet traffic in order to allow content based or- flexible 

15- charging for' different types of traffic. 

The invention also relates to a packet data node allowing 
compensation or correction as referred to above. Still further the 
invention, relates to .a -method for allowing charging correction or 
compensation for lost or unsent data packets on the downlink in a 

2*0 communications system < supporting communication of packet data and 
content based or flexible charging depending on traffic type. 

STATE OF THE ART 

Charging associated with communication with a mobile station is a 
25 problematic issue. Operators at an early stage realized that it is 
risky to base charging on volume as well as on time since it is 
difficult to establish how much of the desired/intended traffic 
that actually reaches the subscriber, or if it is lost or 
discarded on its way on the downlink towards the mobile station, 
30 and further since packets may be resent serveral times. It is 
known to divide or classify different types of traffic e.g. into 
different service classes (QoS) among others depending on how 
urgent traffic is, how important it is that all packets arrive 
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etc. Furthermore it is known to implement different charging 
schemes for different types of traffic, e.g. a content based 
functionality or a flexible (bearer) charging functionality. It is 
known to implement such a functionality on a gateway packet data 
5 node, e.g. GGSN (Gateway GPRS Support Node), which then performs a 
classification of mobile traffic. This classification is then used 
to apply different charging schemes to different types of traffic. 
However, on the downlink, on its way to a mobile station, data 
traffic may be lost or discarded. (Examples thereon are e.g. when 

10 traffic is thrown or discarded due to the fact that it has a lower 
priority when e.g. radio resources are scarce. In GSM/GPRS (UMTS) 
data traffic can be lost or discarded in e.g. the nodes SGSN 
(Serving GPRS Support Node) or in BSC (Base Station Controller) . 
.In e.g. WCDMA data traffic, may be lost in SGSN or RNC (Radio 
. 15 Network Controller) . 

There is still no satisfactory and complete solution for the 
handling of lost traffical packets on the downlink for charging 
purposes if a flexible or content based charging functionality is 
implemented. ,/The GGSN (for example) charges (differently) for 

2 0 different types of traffic (applications) , and sometimes a part of 
the traffic that the subscriber is charged for actually never 
reached the subscriber. This is a serious problem, not only for 
the subscriber, who has to pay for information he did not receive r 
but also for the operator since it severly may reduce and affect 

2 5 customer's confidence in the operator, and the offered services. 

A node comprising the above discussed flexible charging 
functionality classifies the traffic and applies the appropriate 
chargning scheme. However, later on their path towards the 
subscriber, downlinks, packet losses may occur. The amounts of 

30 packets that are lost could be counted in SGSN, but it is not 
possible for SGSN to acguire information as to which type or class 
lost packets belonged to. Even more, it is not possible for GGSN 
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(i.e. the node handling classification and flexible charging) to 
acquire such information. 

SUMMARY OF THE INVENTION 
5 What is needed is therefore an arrangement that allows for more 
accurate charging, i.e. an arrangement through which a user can be 
charged for the packets that actually do arrive to the user. It is 
also needed an arrangement implementing flexible or content 
depending charging through which losses of packets can be taken 
10 into account, irrespectively of where on the downlink such losses 
occur, particularly in an SGSN, a BSC and/or an RNC . 

Still further an arrangement is needed through which more accurate 
charging can be provided, if real time based charging is 
implemented or if CDR (Charging Data Record) based charging is 
15 implemented, i.e. non-real-time based charging. 

Further yet an arrangement is needed which is easy and cheap to 
install and implement, and the operation of which is secure. 

A node for implementing such a functionality in operative 
2 0 cooperation with subsequent nodes downlinks is also needed through 
which one or more of the above mentioned objects can be achieved. 
A method for fulfilling one or more of the above mentioned objects 
is also needed. 

25 Therefore an arrangement as initially referred to and having the 
characterizing features of claim 1 is provided. 

A node having the characterizing features of claim 22 is therfore 
also provided. 

30 Therefore also a method as initially referred to is provided which 
has the characterizing features of claim 26. Advantageous and 
preferred or alternative embodiments are given by the appended 
subclaims . 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will in the following be further described in a non- 
limiting manner, and with reference to the accompanying drawings, 
in which: 

5 

Fig. 1 is a very schematical block diagram illustrating an 
arrangement in an implementation to a GSM/GPRS system 
wherein flexible charging is implemented in GGSN, 



10 Fig. 2 is a very schematical block diagram similar to Fig. 1 
illustrating an implementation to a UMTS/GPRS system 
wherein flexible charging is implemented in GGSN, 

Fig. 3 is a very schematical block diagram similar to Fig. 1 
15 and Fig. 2 for a dual access node (SGSN) and wherein 

flexible charging is implemented, 

Fig. 4 is a block diagram illustrating an implementaion in 
which flexible charging is implemented in SGSN, 

20 

Fig. 5 is a block diagram illustrating a combined gateway and 
serving packet data node (CGSN) supporting flexible 
charging, 

25 Fig. 6 is a signalling diagram for an arrangement as in Fig. 

1, for one particular implementation, 

Fig. 7 is a signalling diagram for an arrangement as in Fig. 2 

for one specific implementation, 

30 

Fig. 8 is a signalling diagram for a dual access SGSN node 

according to another implementation, 
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Fig. 9 is a flow diagram describing the procedure according to 
an implementation in which GGSN supports 
flexible/content based charging, 

5 Fig. 10 is a flow diagram describing the procedure where SGSN 
supports a flexible, content based charging 
functionality, 

Fig. 11 is a flow diagram illustrating an embodiment wherein 
10 reports are included in Charging Data records, 

Fig. 12 is a flow diagram illustrating an embodiment in which 
real time correction/compensation is allowed, 

15 Fig. 13 shows the signal format and introduction of info 
between an access node and an RNC, and 

Fig. 14 shows the signal format and introduction of information 
between an access node and BSC. 



20 



DETAILED DESCRIPTION OF THE INVENTION 



In the embodiment illustrated in Fig. 1 it is supposed that, in a 
GSM/ GPRS system, GGSN 1A supports a type dependent charging 

25 functionality, i.e. charging depends on type of traffic, or 
service class belonging of the traffic (e.g. IP flow based bearer 
level charging) . GGSN 1A communicates with SGSN 2A over the Gn- 
interface using the GTP (GPRS Tunneling Protocol) as is known per 
se, cf. 3GPP TS 29.060, which herewith is incorporated herein by 

30 reference. GGSN 1A here adds traffic type information (identified 
as a part of a type dependent charging functionality including 
classification of traffic, or separately obtaining 

type/classification information) to the GTP header of the downlink 
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(DL) payload. The type information may be of different kinds , it 
may e.g. contain service class information, e.g. a service class 
tag. In addition thereto it may contain cost or rating 
information. It may also, in an advantageous implementation, 
5 contain chain id, which is used to identify the chain an IP packet 
belongs to when IP packets sharing the same service class cannot 
be identified until the key-IP packet for the particular chain has 
arrived at GGSN, or until a required number of packets have 
arrived. If this information is not included, it should be noted 
10 that loss of such a packet cannot be compensated for, but in some 
cases this might be acceptable. 

SGSN 2A provides for the type information (at least) being sent 
also to BSC 3A (in this case) . Only one BSC is shown in the figure 
for reasons of clarity. As is known the G b interface is used 

15 between BSC and SGSN and BSSGP is used as communication protocol. 
BSSGP, Base Station System GPRS Protocol is described in 3GPP TS 
48.018, which herewith is incorporated herein by reference. Since 
different protocols are used between GGSN and SGSN and SGSN and 
BSC respectively, the type info cannot simply be forwarded by SGSN 

20 to BSC, but instead a new information element with at least the 
type information may be added to the BSSGP DL-UNITDATA PDU (Packet 
Data Unit) . MS 4A is shown merely for illustrative purposes in the 
figure . 

Traffic can be discarded either by SGSN 2A or by BSC 3A. In case 
25 SGSN 2A discards traffic, the type information (at least) of the 
the discarded payload is added to the CDR (in a new field 
thereof) . A loss report is sent to GGSN 1A if real-time 
compensation is implemented. In this embodiment it is not limited 
to sending of loss reports in any specific manner. It can be done 
30 based on time, volume, CDR: s may be used in a conventional manner 
by the operator to provide for compensation on a more or less 
regular basis, e.g. at night, when CDR:s are checked in any case. 
This will be further discussed below. 
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If instead it is BSC 3A that discards traffic -this is reported in 
a loss report to SGSN 2A. This is illustrated in the figure but it 
may just as well be SGSN that discards traffic; SGSN has to report 
it to GGSN irrespectinely if it being SGSN itself or BSC that has 
5 discarded traffic if real-time compensation is supported. In this 
embodiment BSC 3A notes the type information (e.g. at least 
service class tag) in the BSSGP header and includes it as a new 
information element in the BSSGP header, as a new information 
element in BSSGP LLC (Logical Link Control) Discarded message 
10 towards SGSN 2A. (Real time compensation may be supported or not 
as discussed above) . 

When a loss report from BSC 3A, i.e. a report of discarded 
traffic, is received in SGSN 2A, this information is included in 
the appropriate CDR in a new field by SGSN 2A. The CDR can then be 

15 post-processed together with the data of the type dependent 
charging functionality provided by the GGSN 1A to allow for a 
charging in which compensation is provided for lost traffic. 
If real time compensation should be supported, a new GTP message, 
e.g. GTP Discarded traffic report has to be sent to the GGSN 1A 

20 (both if SGSN or BSC discarded the traffic) containing the 
information of the loss report together with IMSI and NSAPI 
(Network layer Service Access Point Identifier) . If real time 
compensation is implemented, it is not, for the functioning of the 
inventive concept, necessary to include the loss report 

2 5 information in a CDR, but it may be advantageous to do so in order 
to keep the information that might be useful. 

Fig. 2 is a Fig similar to Fig. 1 but with the difference that 
SGSN 2B supports communication with RNC 3B (UMTS) . Also here it is 
30 supposed that GGSN IB supports a type dependent charging 
functionality. MS 4B is merely shown for reasons of completeness. 
The interface used between SGSN 2B and RNC 3B is Iu as is known 
per se. However, in this case the GTP protocol is used also 
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between SGSN 2B and RNC 3B, which makes it easier. The type 
information may then simply be forwarded from SGSN 2B as e.g. the 
same service tag to the RNC 3B. If RNC 3B discards traffic, it 
notes the type info, e.g. at least service tag as discussed with 
5 reference to Fig. 1, and sends this information as a new 
information element in RANAP Data Volume Report to SGSN 2B. (For 
non-real time compensation the message may be sent either when a 
RAB (Radio Access Bearer) is lost, or when PDP context is 
deactivated, whereas for real-time implementations the report 

10 should be sent immediately when traffic is discarded.) 

RANAP, Radio Access Network Application Part, is discussed in 3GPP 
TS 25.413, which herewith is incorporated herein by reference. 
When a loss report (Data Volume Report) is received in SGSN, this 
info may be included in the correct CDR in a new field as 

15 discussed with reference to Fig. 1. 

It should be noted that for non-real time embodiments, the loss 
report does not have to be sent to GGSN, whereas for real time 
compensation embodiments the report has to be provided to GGSN 
(with IMSI and NSAPI (or correspondingly) as discussed above) . 

2 0 Generally the invention suggests a mechanism that makes it 
possible for an SGSN to identify which traffic class and 
cost/rating information discarded traffic had been allocated by a 
GGSN. 

2 5 Fig. 3 is an embodiment in which the SGSN 2C (in communication 
with GGSN 1C) comprises a Dual Access Node supporting 
communication with BSC 3C as well as with RNC 3C . MS 4C, 4C are 
illustrated for reasons of completeness. 

The functioning is the same as that described above with reference 
30 to Figs. 1 and 2, real time handling being supported or not, loss 
reports to GGSN 1C only being relevant for real time charging 
cases, whereas if CDR based charging is implemented, this is not 
necessary . 
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Fig. 4 shows an alternative implementation in which the type 
dependent, or flexible, charging functionality is provided in SGSN 
2D instead of in GGSN ID. It is here supposed that SGSN 2D is a 
dual access node supporting communication with BSC 3D as well as 
5 RNC 3D' . However, the inventive concept of course also covers the 
case when SGSN 2D only supports BSC 3D or RNC 3D' . The functioning 
is the same as that described with reference to Figs. 1-3 with the 
difference that sending of type info (e.g. service class tag and 
possibly cost/rating info and/or chain id) between GGSN ID and 
10 SGSN 2D is not necessary, neither to send any loss reports to 
GGSN. 

Fig. 5 shows still another implementation wherein a CGSN IE is 
implemented which comprises the functionality of both a GGSN and a 
15 SGSN. CGSN IE may support a dual access functionality or not i.e. 
support both or either of BSC 3E, RNC 3E' . The functioning is the 
same as that described in the foregoing, with the difference that 
no communication with a separate GGSN is needed, which thus makes 
the procedure even more straightforward. 

20 

Fig. 6 is a signalling diagram illustrating the inventive 
procedure for an embodiment in which flexible/content based 
charging is supported in GGSN, in which SGSN supports 
communication with BSC:s and in which it is allowed for real time 

25 compensation of lost traffic. 

It is here supposed that GGSN adds service class tag and a time 
stamp to the GTP header of the DL payload, 1. A time stamp is here 
used as an alternative to sending cost/rating info, which instead 
is identified in GGSN when a discarded traffic report with time 

30 stamp is received in GGSN. Chain id may be included or not. SGSN 
adds a new information element to BSSGP DL -UN I T DATA , 2, and sends 
the service class tag info and time stamp on to BSC. 
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If SGSN discards traffic, a GTP Discarded traffic report with 
IMSI, NSAPI, service class tag, volume and time stamp is sent to 
GGSN in a new GTP message, 3, substantially immediately at 
occurrence of the loss. 
5 If on the other hand BSC discards traffic, BSC includes the 
relevant info, here service class tag, volume, time stamp in a 
BSSGP LLC Discarded message towards SGSN, 3' . 

To enable real-time compensation in the GGSN, a new GTP message, 
e.g. GTP discarded traffic report with IMSI, NSAP1, service class 
10 tag, volume and time stamp (here) is sent to GGSN, 4 F , 
substantially as soon as SGSN detects or is informed of the loss. 

In the signalling diagram of Fig. 7 it is supposed that the SGSN 
access node only supports RNC communication. In the other aspects 

15 the same principles as in the embodiment of Fig. 6 apply. Thus, 
here the service class tag and the time stamp is simply forwarded, 
2, by SGSN to RNC since also between SGSN and RNC the GTP protocol 
is used (GTP-U, userplane) . If RNC discards traffic, RNC sends a 
volume report with service class tag, volume and time stamp to 

20 SGSN, 3' . The signalling denoted 1, 3, 4' in Fig. 7 corresponds to 
the signalling with the corresponding references in Fig. 6. 

Fig. 8 is a signalling diagram relevant for another implementation 
supporting real-time compensation for lost packets. It is here 

25 supposed that SGSN is a dual access node, but an implementation as 
in Fig. 8 of course also is possible if SGSN only supports BSC or 
RNC, in which cases the corresponding signalling to/from the node 
not supported should be deleted from Fig. 8. Like in Figs 6, 7 it 
is supposed that a flexible charging functionality is supported by 

30 GGSN. The difference from Figs 6, 7 is that the information 
provided to SGSN, BSC and/or RNC contains service class tag, 
rating info and chain id and that the loss reports contain IMSI, 
NSAPI, service class tag, volume, rating info and chain id. 
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If flexible charging is supported by SGSN or if SGSN and GGSN are 
combined into a CGSN, the messageing between SGSN-GGSN is of 
course superfluous . 

5 Fig. 9 illustrates, in the form of a flow diagram, the procedure 
when GGSN supports flexible/content based charging. GGSN here adds 
service class info (and preferably rating info and chain id) to 
the GTP header of the downlink (DL) payload, and sends to SGSN, 
100. SGSN sends service class info (rating info, chain id) to BSC 

10 and/or RNC, 101. If /when traffic is discarded by SGSN, 102 yes, 
service class info (rating info, chain id) of the discarded 
payload is provided to GGSN and registered by SGSN, 103 (for a 
real time implementation) . If (when) traffic is discarded by 
BSC/RNC, 104 yes, service class info (rating info, chain id) of 

15 the discarded payload is provided to SGSN and registered by 
BSC/RNC/SGSN, 105. Subsequently, for real time compensation, 
service class info (rating info, chain id) of discarded payload is 
provided from SGSN to GGSN, 10 6. 

For real time implementations loss reports to SGSN/ GGSN are 
20 provided substantially immediately upon occurrence to GGSN, 
including e.g. IMSI, NSAPI as discussed above. 

Fig. 10 is a flow diagram describing a procedure as in Fig. 9, but 
wherein the flexible/content based charging functionality is 
25 supported by SGSN. As can be seen only steps 101, 104 and 105 
remain, here denoted 200, 201, 202. As can be seen, the procedure 
is considerably facilitated. 

The functioning will be substantially the same if a CGSN node is 
used. 

30 

Fig. 11 is a flow diagram describing an implementation of the 
inventive concept when CDR based charging (not in real time) is 
implemented. As discussed above, GGSN adds a service class tag to 
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the downlink payload sent to SGSN, 301. SGSN sends/forwards the 
service class tag to RNC/BSC, 302. If traffic is discarded by 
SGSN, the service class tag is added to the appropriate Call Data 
Record (CDR) in a new field, 303, and compensation for lost 
5 traffic is performed e.g. by the operator using information as to 
type etc provided by GGSN when the CDR is handled, e.g. at night. 
If traffic is discarded by RNC, RNC notes the service tag of the 
discarded traffic and sends this info as a new information element 
in a RANAP Data Volume Report. If traffic is discarded by BSC, BSC 
10 notes the service tag in the BSSGP header, includes it in a BSSGP 
LLC Discarded message towards SGSN, 304. 

When such a discarded traffic report is received in SGSN, the 
report info is included in the appropriate CDR in a new field, cf. 
step 303 above. After step 303 and/or 305, the CDR is post- 
15 processed together with the flexible charging data info provided 
to SGSN by GGSN to provide for accurate charging with lost traffic 
compensation, 306 . 

Fig. 12 illustrates a procedure allowing for charging compensation 
20 for lost packets in real time. In the shown embodiment GGSN adds 
service class tag, rating info, chain id to the DL payload GTP 
header sent to SGSN, 401. SGSN in turn sends/forwards service 
class tag rating info, chain id to RNC and/or BSC, 402. 
If traffic is discarded by SGSN, service class tag, rating info, 
25 chain id of the discarded payload may be added to the appropriate 
CDR in a new field, and a new GTP message is sent to GGSN with 
this information together with IMSI, NSAPI substantially 
instantaneously, 403. If RNC and/or BSC dicards traffic, service 
class tag, rating info, chain id are provided to SGSN immediately 
30 upon traffic discarding, 404. Report information about the 
discarded traffic may then be included in the correct CDR in a new 
field in SGSN. A new GTP message with such info and IMSI, NSAPI is 
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then sent to GGSN, 405. (cf. step 403). Charging is then 
corrected/compensated for lost traffic in real time in GGSN, 406. 

Fig. 13 shows the signalling format used between GGSN-SGSN and 
5 SGSN-RNC which use the GTP protocol. The information (e.g. service 
tag, rating info and chain id), is introduced in the GTP header. 

Fig. 14 shows the format used between SGSN and BSC. The relevant 
information is here introduced into BSSGP. The format is known as 
10 such, NS, Network service, LLC, SNDCP Sub Network Dependent 
Convergence Protocol . 

According to the invention it gets possible to compensate flexible 
charging for downlink payload discarded by e.g. BSC, RNC, SGSN or 
15 a node with a similar functionality. 

It should be clear that the invention is not limited to the 
specifically illustrated embodiments, but that it can be varied in 
a number of ways within the scope of the appended claims . 
20 It should also be clear that other nodes in other communication 
systems having similar functionalities as e.g. GGSN, SGSN, CGSN, 
BSC also are covered by the inventive concept. 

25 



30 



